1. Field of Invention
The present invention relates to context-aware systems, in particular to context-aware systems employing sensors of varying availability.
2. Discussion of Background
Context-awareness is a key technology for the next generation of smart devices. These devices will not only know where they are, by whom they are used, and what other devices are around them, they will have a broad knowledge about what a user's desires and needs are and will act accordingly. To implement that, the devices will therefore need to utilise numerous internal and external sensors for collecting enough information to derive context information reliably.
Context, as it is used in this specification is defined by Anind Dey in “Understanding and using context”, Personal and Ubiquitous computing, special issue on Situated Interaction and Ubiquitous Computing”, Vol. 5(1), 2001, page 4-7, as any information that can be used to characterise the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves. The entity for which context information is collected is furthermore addressed as focus entity.
Knowledge about a context can be used in various ways to make applications and devices much smarter by automatically incorporating this context information. Unfortunately, context is rather complex and therefore hard to handle. The complexity results from the multiplicity of different types of context potentially derived from numerous different sensors. A tourist, e.g., moving around in a foreign city is supplied by his context-aware device with an active map and additionally with information about the sights he or she is currently viewing. In this case, the context-aware device will need—among others—information about the current location of the tourist. For the tourist being outdoors, this information can be obtained by using a Global Positioning System (GPS) but indoors, this is no longer feasible because accessing GPS satellites is impossible from within buildings. Consequently, special indoor location systems are to be used for retrieving the position information indoors. Whenever a user moves into or out of a building, his or her context-aware device has to switch to another location defining system. Handling this take-over from the outdoor to the indoor location defining system and vice a versa is currently performed on the application side, which works quite well when there are only a few possible sources of information available.
As soon as a large number of different sources have to be considered, this approach becomes impracticable. The tourist of the above example might for instance not only be interested in his own position, but also wants to know if certain persons move in or out of a certain area, e.g. if his children are going to far away. For this, a system has to utilise a large number of location sensors of different types—indoor as well as outdoor—whereby the indoor location type might also differ from building to building and therefore from person to person. The context-aware device will have to deal with this, and might have to implement the access to different types of location sensors at the same time. The configuration of a context-aware device will become even more complicated, if not only location information is used, but a wide range of different information sources like for temperature, pressure or the like to create a more complex context structure.
Anind Dey discloses a Context Toolkit developed at the Georgia Institute of Technology in “Providing Architectural Support for Building Context-Aware Applications”, PhD theses, College of Computing, Georgia Institute of Technology, December 2000. The purpose of the context tool kit is to hide the process of gathering context information in the same way that X-window widgets hide the complexity of the X-windows system from an application developer. Widgets represent a certain kind of information like e.g. a location or an activity based on data provided by sensors. X-window widgets accumulate complex graphical user interface handling functionality into one component and are accessed via a uniform interface thereby hiding the details of an underlying sensor configuration. Context aggregators sum up a number of widgets to a more complex “meta-widget” providing access to more complex context information. Interpreters transform low-level context information like a location or an activity to a more abstract higher level information, like e.g. by deducing from the information that somebody is lying in a bed with a regular low pulse that this particular person is sleeping.
The Context Toolkit is the currently most popular context handling system. It is very easy to use and simplifies the implementation of context-aware applications by providing widgets and interpreters for frequently used context types. The Context Toolkit assumes that the sensor configurations are static, i.e. the application developer determines at design time which widgets, interpreters and aggregators are to be used. Because no reconfiguration of the system is supported, the inflexible structure yields the problem, that if a sensor fails the error is propagated up to the application level.
The European funded Youngster project (IST-2000-25034) develops technologies to create a new open active mobile multimedia environment that is accessible from anywhere by a wide range of devices and networks, and that supports context-aware features including location-awareness.
Within the project, a context system for a mobile platform is evaluated, proposing in principle that all requests from context clients, i.e. context-aware devices are passed to a local context service. This service tries to resolve the requests locally by either providing shortcuts to local context sources or by reusing existing connections to context servers. If a request cannot be resolved locally, it is passed to a remote context server for further processing. Context service and context server may reside on the same host. Context sources have direct access to sensors and transform the sensor data into a format that is understood by the context server. Context sources might also be located within the server accessing the sensors only remotely.
The term context client refers to an entity requesting context information, while the term context server refers to an entity providing context information. Context clients request context information from a context server by specifying the desired information, like e.g. location. The mapping of the desired information type to the available sensors is done via the context server.
A context server creates paths from a requested data type to the available sensors. If a request cannot be mapped directly to respective sensors, a data transformation via so called context interpreters is performed.
With the paths created, a context information originates from a sensor and is afterwards translated by a context source from a proprietary format into a Youngster internal format that is understood by appropriate context interpreters. The context interpreters themselves process data and are composed within a chain. In the end of the chain, data in the originally requested format are stored in a context attribute which itself is part of a bigger data structure, the aggregator. The context attribute specifies the format, the type and through the parent context aggregator also the focus entity of the stored data.
In the context system for mobile service platforms as proposed in the Youngster project, clients do not need to have knowledge about available sensors or how to put them to use, but can transfer this task completely to the context system. The mapping from the desired type and format for the requested context information to the available sensors is done by the server by automatically creating a so-called context path. The path can be implemented in form of a linear path or a more complex structure with sensor hierarchies utilising basic and abstract sensors. Abstract sensors collect data from different basic sensors and transform the data to a certain degree. The configuration of the context path shows a tree structure with the root node being a context attribute that can be accessed from a context client.
The path from a requested data type to the available sensors has to be set up manually, which means that e.g. for all desired types and formats of context attributes a chain of context interpreters and sources has to be created and connected manually. Another possibility is to have the context clients specify what context interpreters and context attributes to use and how to connect them according to rules defined by the client. Although the advantages of an automatic and on-demand creation of a context path, like keeping the constructions of context clients simple, providing flexibility both on the client as well as on the server side, and an ease of maintenance are very obvious, no mechanism for automatically creating a context path is presently available.